<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.14"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>dp: Main Page</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="navtree.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="resize.js"></script>
<script type="text/javascript" src="navtreedata.js"></script>
<script type="text/javascript" src="navtree.js"></script>
<script type="text/javascript">
  $(document).ready(initResizable);
</script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
<link href="HTML_custom.css" rel="stylesheet" type="text/css"/>
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
 <tbody>
 <tr style="height: 56px;">
  <td id="projectlogo"><img alt="Logo" src="xlogo_bg.gif"/></td>
  <td id="projectalign" style="padding-left: 0.5em;">
   <div id="projectname">dp
   </div>
   <div id="projectbrief">Xilinx SDK Drivers API Documentation</div>
  </td>
 </tr>
 </tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.14 -->
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
$(function() {
  initMenu('',false,false,'search.php','Search');
});
</script>
<div id="main-nav"></div>
</div><!-- top -->
<div id="side-nav" class="ui-resizable side-nav-resizable">
  <div id="nav-tree">
    <div id="nav-tree-contents">
      <div id="nav-sync" class="sync"></div>
    </div>
  </div>
  <div id="splitbar" style="-moz-user-select:none;" 
       class="ui-resizable-handle">
  </div>
</div>
<script type="text/javascript">
$(document).ready(function(){initNavTree('index.html','');});
</script>
<div id="doc-content">
<div class="header">
  <div class="headertitle">
<div class="title">dp Documentation</div>  </div>
</div><!--header-->
<div class="contents">
<div class="textblock"><p>The Xilinx DisplayPort transmitter (DP) driver. This driver supports the Xilinx DisplayPort soft IP core in both transmit/source (TX) and receive/sink (RX) modes of operation.</p>
<p>The Xilinx DisplayPort soft IP supports the following features:</p><ul>
<li>1, 2, or 4 lanes.</li>
<li>A link rate of 1.62, 2.70, or 5.40Gbps per lane.</li>
<li>1, 2, or 4 pixel-wide video interfaces.</li>
<li>RGB and YCbCr color space.</li>
<li>Up to 16 bits per component.</li>
<li>Up to 4Kx2K monitor resolution.</li>
<li>Auto lane rate and width negotiation.</li>
<li>I2C over a 1Mb/s AUX channel.</li>
<li>Secondary channel audio support (2 channels).</li>
<li>4 independent video multi-streams.</li>
</ul>
<p>The Xilinx DisplayPort soft IP does not support the following features:</p><ul>
<li>The automated test feature.</li>
<li>Audio (3-8 channel).</li>
<li>FAUX.</li>
<li>Bridging function.</li>
<li>MST audio.</li>
<li>eDP optional features.</li>
<li>iDP.</li>
<li>GTC.</li>
</ul>
<p><b>DisplayPort overview</b></p>
<p>A DisplayPort link consists of:</p><ul>
<li>A unidirectional main link which is used to transport isochronous data streams such as video and audio. The main link may use 1, 2, or 4 lanes at a link rate of 1.62, 2.70, or 5.40Gbps per lane. The link needs to be trained prior to sending streams.</li>
<li>An auxiliary (AUX) channel is a 1MBps bidirectional channel used for link training, link management, and device control.</li>
<li>A hot-plug-detect (HPD) signal line is used to determine whether a DisplayPort connection exists between the DisplayPort TX connector and an RX device. It is serves as an interrupt request by the RX device.</li>
</ul>
<p><b>Device configuration</b></p>
<p>The device can be configured in various ways during the FPGA implementation process. Configuration parameters are stored in the xdp_g.c file which is generated when compiling the board support package (BSP). A table is defined where each entry contains configuration information for the DisplayPort instances present in the system. This information includes parameters that are defined in the driver's data/dp.tcl file such as the base address of the memory-mapped device and the maximum number of lanes, maximum link rate, and video interface that the DisplayPort instance supports, among others.</p>
<p>The DisplayPort core may be configured in both transmitter (TX) or receiver (RX) modes of operation. Depending on which mode of operation the hardware is configured for, the set of registers associated with the core will be different.</p>
<p><b>Driver description</b></p>
<p>The DisplayPort (DP) driver consists of functions, structures, and definitions: 1) Specific to the DisplayPort TX mode of operation.</p><ul>
<li>Prefix: XDp_Tx* and XDP_TX_* 2) Specific to the DisplayPort RX mode of operation.</li>
<li>Prefix: XDp_Rx* and XDP_RX_* 3) Common to both DisplayPort modes of operation.</li>
<li>Prefix: XDp_* and XDP_*</li>
</ul>
<p><b>Driver description: TX mode of operation</b></p>
<p>The device driver enables higher-level software (e.g., an application) to configure and control a DisplayPort TX soft IP, communicate and control an RX device/sink monitor over the AUX channel, and to initialize and transmit data streams over the main link. This driver follows the DisplayPort 1.2a specification.</p>
<p>This driver implements link layer functionality: a Link Policy Maker (LPM) and a Stream Policy Maker (SPM) as per the DisplayPort 1.2a specification.</p><ul>
<li>The LPM manages the main link and is responsible for keeping the link synchronized. It will establish a link with a downstream RX device by undergoing a link training sequence which consists of:<ul>
<li>Clock recovery: The clock needs to be recovered and PLLs need to be locked for all lanes.</li>
<li>Channel equalization: All lanes need to achieve channel equalization and and symbol lock, as well as for interlane alignment to take place.</li>
</ul>
</li>
<li>The SPM manages transportation of an isochronous stream. That is, it will initialize and maintain a video stream, establish a virtual channel to a sink monitor, and transmit the stream.</li>
</ul>
<p>Using AUX transactions to read/write from/to the sink's DisplayPort Configuration Data (DPCD) address space, the LPM obtains the link capabilities, obtains link configuration and link and sink status, and configures and controls the link and sink. The main link is trained this way.</p>
<p>I2C-over-AUX transactions are used to obtain the sink's Extended Display Identification Data (EDID) which give information on the display capabilities of the monitor. The SPM may use this information to determine what available screen resolutions and video timing are possible.</p>
<p><b>Driver description: RX mode of operation</b></p>
<p>The device driver enables higher-level software (e.g., an application) to configure and control a DisplayPort RX soft IP.</p>
<p>This driver gives applications the ability to configure the RX using various settings, handle and issue interrupts, and modify a subset of its DisplayPort Configuration Data (DPCD) fields.</p>
<p>Link training is done automatically by the hardware.</p>
<p><b>Interrupt processing</b></p>
<p>For the driver to process interrupts, the application must set up the system's interrupt controller and connect the XDp_InterruptHandler function to service interrupts. When an interrupt occurs, XDp_InterruptHandler will check which mode of operation the DisplayPort core is running in, and will call the appropriate interrupt handler for that core (XDp_TxInterruptHandler or XDp_RxInterruptHandler - local to <a class="el" href="xdp__intr_8c.html">xdp_intr.c</a>).</p>
<p><b>Interrupt processing: TX mode of operation</b></p>
<p>DisplayPort interrupts occur on the HPD signal line when the DisplayPort cable is connected/disconnected or when the RX device sends a pulse. The user hardware design must contain an interrupt controller which the DisplayPort TX instance's interrupt signal is connected to. The user application must enable interrupts in the system and set up the interrupt controller such that the XDp_TxHpdInterruptHandler handler will service DisplayPort interrupts. When the XDp_TxHpdInterruptHandler function is invoked, the handler will identify what type of DisplayPort interrupt has occurred, and will call either the HPD event handler function or the HPD pulse handler function, depending on whether a an HPD event on an HPD pulse event occurred.</p>
<p>The DisplayPort TX's XDP_TX_INTERRUPT_STATUS register indicates the type of interrupt that has occurred, and the XDp_TxInterruptHandler will use this information to decide which handler to call. An HPD event is identified if bit XDP_TX_INTERRUPT_STATUS_HPD_EVENT_MASK is set, and an HPD pulse is identified from the XDP_TX_INTERRUPT_STATUS_HPD_PULSE_DETECTED_MASK bit.</p>
<p>The HPD event handler may be set up by using the XDp_TxSetHpdEventHandler function and, for the HPD pulse handler, the XDp_TxSetHpdPulseHandler function.</p>
<p><b>Interrupt processing: RX mode of operation</b></p>
<p>The DisplayPort RX driver may generate a pulse on the hot-plug-detect (HPD) signal line using the XDp_RxGenerateHpdInterrupt function. This allows the RX to send an interrupt to the upstream TX device, useful for signaling the TX that it needs to do some checks for changes in downstream devices or a loss of link training.</p>
<p>For RX interrupt handling of HPD events or events that happen internal to the RX, the user hardware design must contain an interrupt controller which the DisplayPort RX instance's interrupt signal is connected to. The user application must enable interrupts in the system and set up the interrupt controller such that the XDp_RxInterruptHandler handler will service interrupts. When the XDp_RxInterruptHandler function is invoked, the handler will identify what type of interrupt has occurred, and will call the appropriate interrupt handler.</p>
<p>The DisplayPort RX's XDP_RX_INTERRUPT_CAUSE register indicates the type of interrupt that has occured, and the XDp_RxInterruptHandler will use this information to decide which handler to call.</p>
<p>The handlers are set up using the XDp_RxSetIntr* functions.</p>
<p>Specific interrupts may be enabled or disabled using the XDp_RxInterruptEnable and XDp_RxInterruptDisable functions.</p>
<p><b>Multi-stream transport (MST) mode: TX mode of operation</b></p>
<p>The driver handles MST mode functionality in TX mode of operation, including sideband messaging, topology discovery, virtual channel payload ID table management, and directing streams to different sinks.</p>
<p>MST testing has been done at all possible link rate/lane count/topology/ resolution/color depth combinations with each setting using following values:</p><ul>
<li>Link rate: 1.62, 2.70, and 5.40Gbps per lane.</li>
<li>Lane count: 1, 2, and 4 lanes.</li>
<li>Number of sink displays: 1, 2, 3, and 4 sink displays in both a daisy-chain configuration and in a configuration using a combination of a 1-to-3 hub and daisy-chain. Each stream was using the same resolution.</li>
<li>Resolutions (60Hz): 640x480, 800x600, 1024x768, 1280x800, 1280x1024, 1360x768, 1400x1050, 1680x1050, 1920x1080, 1920x2160, and 3840x2160.</li>
<li>Color depths: 18, 24, 30, 36, and 48 bits per pixel.</li>
</ul>
<p><b>Multi-stream transport (MST) mode: RX mode of operation</b></p>
<p>The driver handles MST mode functionality in RX mode of operation. The API function, XDp_RxHandleDownReq, will read a sideband message from the down request registers in the DisplayPort RX core, parse it, arbitrate control for the sideband message type that was requested, format a reply, and send the reply.</p>
<p>The current version of the driver only supports a software representation of a shallow topology - meaning virtual sinks are defined in the user application and assigned to port numbers. The RX acts as a branch connected to multiple sinks, but is not connected to another branch. Sideband messages will then be handled for the targeted downstream sink.</p>
<p>The user application creates the topology using the driver's API functions:</p><ul>
<li>XDp_RxSetIicMapEntry : Used to specify the I2C contents of a virtual sink.</li>
<li>XDp_RxSetDpcdMap : Used to specify the DPCD of a virtual sink.</li>
<li>XDp_RxMstSetPbn : Used to specify the available PBN of a virtual sink.</li>
<li>XDp_RxMstSetPort : Used to specify how the sink will appear when the an upstream device sends a LINK_ADDRESS sideband request to the RX branch.</li>
<li>XDp_RxMstSetInputPort : Used to specify the input port.</li>
<li>XDp_RxMstExposePort : Used to enable the port by exposing it to incoming LINK_ADDRESS sideband requests.</li>
</ul>
<p>The driver will keep track of the topology in the structures:</p><ul>
<li><a class="el" href="struct_x_dp___rx_topology.html" title="This typedef contains topology information on directly connected sinks and of the RX branch itself...">XDp_RxTopology</a> : Stores topology information as a reply to LINK_ADDRESS requests, the virtual channel payload table, and port representations (<a class="el" href="struct_x_dp___rx_port.html" title="This typedef contains information on the directly connected ports to the RX branch. ">XDp_RxPort</a>[] type).</li>
<li><a class="el" href="struct_x_dp___rx_port.html" title="This typedef contains information on the directly connected ports to the RX branch. ">XDp_RxPort</a> : Stores the I2C map (<a class="el" href="struct_x_dp___rx_iic_map_entry.html" title="This typedef represents one I2C map entry for a device. ">XDp_RxIicMapEntry</a>[] type), DPCD address space (<a class="el" href="struct_x_dp___rx_dpcd_map.html" title="This typedef represents the DPCD address map for a device. ">XDp_RxDpcdMap</a> type), PBN information, and whether or not the represented sink is exposed to upstream devices.</li>
<li><a class="el" href="struct_x_dp___rx_iic_map_entry.html" title="This typedef represents one I2C map entry for a device. ">XDp_RxIicMapEntry</a> : Represents data stored at an associated I2C address.</li>
<li><a class="el" href="struct_x_dp___rx_dpcd_map.html" title="This typedef represents the DPCD address map for a device. ">XDp_RxDpcdMap</a> : Represents the DPCD of an associated port's sink.</li>
</ul>
<p>Note that the driver uses the topology's <a class="el" href="struct_x_dp___rx_port.html" title="This typedef contains information on the directly connected ports to the RX branch. ">XDp_RxPort</a>[] array such that the indices match the port number that attaches the virtual sink to the RX branch.</p>
<p>The following sideband messages are supported:</p><ul>
<li>CLEAR_PAYLOAD_ID_TABLE</li>
<li>LINK_ADDRESS</li>
<li>REMOTE_I2C_READ</li>
<li>REMOTE_DPCD_READ</li>
<li>ENUM_PATH_RESOURCES</li>
<li>ALLOCATE_PAYLOAD Other sideband messages are replied to with NACK.</li>
</ul>
<p><b>Audio</b></p>
<p>The driver in RX mode of operation may received audio info and extension packets. When this happens, if interrupts are enabled, the appropriate handlers will be invoked. Control functions are available for enabling, disabling, and resetting audio in the DisplayPort RX core.</p>
<p>The TX driver does not handle audio. For an example as to how to configure and transmit audio, examples/xdptx_audio_example.c illustrates the required sequence in the TX mode of operation. The user will need to configure the audio source connected to the Displayport TX instance and set up the audio info frame as per user requirements.</p>
<p><b>Asserts</b></p>
<p>Asserts are used within all Xilinx drivers to enforce constraints on argument values. Asserts can be turned off on a system-wide basis by defining, at compile time, the NDEBUG identifier. By default, asserts are turned on and it is recommended that application developers leave asserts on during development.</p>
<p><b>Limitations: TX mode of operation</b></p>
<ul>
<li>For MST mode to correctly display, the current version of the driver requires that each of the DisplayPort TX streams be allocated without skipping streams (i.e. assign stream 1, stream 2, and stream 3 - problems were experienced if skipping stream 2 and assigning stream 4 instead). skipping monitors in a daisy chain is OK as long as they are assigned to streams in order.</li>
<li>In MST mode, the current version of the driver does not support removal of an allocated stream from the virtual channel payload ID table without clearing the entire table.</li>
<li>Some sideband messages have not been implemented in the current version of the driver for MST mode. Notably, reception of a CONNECTION_STATUS_NOTIFY sideband message.</li>
<li>The driver does not handle audio. See the audio example in the driver examples directory for the required sequence for enabling audio.</li>
</ul>
<p><b>Limitations: RX mode of operation</b></p>
<ul>
<li>Sideband messages that aren't supported as specified above will be NACK'ed.</li>
</ul>
<dl class="section note"><dt>Note</dt><dd>For a 5.4Gbps link rate, a high performance 7 series FPGA is required with a speed grade of -2 or -3.</dd></dl>
<pre>
MODIFICATION HISTORY:</pre><pre>Ver   Who  Date     Changes
<hr/>

1.0   als  01/20/15 Initial release. TX code merged from the dptx driver.
2.0   als  06/08/15 Added MST functionality to RX. New APIs:
                        XDp_RxHandleDownReq, XDp_RxGetIicMapEntry,
                        XDp_RxSetIicMapEntry, XDp_RxSetDpcdMap,
                        XDp_RxMstExposePort, XDp_RxMstSetPort,
                        XDp_RxMstSetInputPort, XDp_RxMstSetPbn,
                        XDp_RxSetIntrDownReqHandler,
                        XDp_RxSetIntrDownReplyHandler,
                        XDp_RxSetIntrAudioOverHandler,
                        XDp_RxSetIntrPayloadAllocHandler,
                        XDp_RxSetIntrActRxHandler,
                        XDp_RxSetIntrCrcTestHandler
                    Added Intr*Handler and Intr*CallbackRef interrupt-related
                    members to <a class="el" href="struct_x_dp___rx.html" title="The XDp driver instance data representing the RX mode of operation. ">XDp_Rx</a> structure for:
                        DownReq, DownReply, AudioOver, PayloadAlloc, ActRx,
                        CrcTest
                    Added new data structures related to RX MST topology:
                        <a class="el" href="struct_x_dp___rx_iic_map_entry.html" title="This typedef represents one I2C map entry for a device. ">XDp_RxIicMapEntry</a>, <a class="el" href="struct_x_dp___rx_dpcd_map.html" title="This typedef represents the DPCD address map for a device. ">XDp_RxDpcdMap</a>, <a class="el" href="struct_x_dp___rx_port.html" title="This typedef contains information on the directly connected ports to the RX branch. ">XDp_RxPort</a>,
                        <a class="el" href="struct_x_dp___rx_topology.html" title="This typedef contains topology information on directly connected sinks and of the RX branch itself...">XDp_RxTopology</a>
                    Renamed XDp_Tx* to XDp_* to reflect commonality with RX
                    for:
                        XDp_TxSbMsgLinkAddressReplyPortDetail
                        XDp_TxSbMsgLinkAddressReplyDeviceInfo
                    GUID type change for ease of use:
                        'u32 Guid[4]' changed to 'u8 Guid[16]'
                    Added handlers and setter functions for HDCP and unplug
                    events.
                    Added callbacks for lane count changes, link rate changes
                    and pre-emphasis + voltage swing adjust requests.
3.0   als  10/07/15 Added MSA callback.
4.0   als  12/08/15 Added link rate and lane count validity check APIs:
                        XDp_IsLinkRateValid
                        XDp_IsLaneCountValid
                    XDp_TxAllocatePayloadVcIdTable now takes an additional
                    argument (StartTs, the starting timeslot).
                    Added RX API to get color depth of a given stream.
                        XDp_RxGetBpc
                    Added RX API to get color component format of a stream.
                        XDp_RxGetColorComponent
                    Added RX API to set end of line reset as appropriate.
                        XDp_RxSetLineReset
                    Added RX MST API to allocate payload from ISR:
                        XDp_RxAllocatePayloadStream
5.0   als  05/16/16 Added APIs to set color encoding scheme.
5.1   als  08/12/16 Updates to support 64-bit base addresses.
      ms   01/23/17 Added xil_printf statement in main function for all
                    examples to ensure that "Successfully ran" and "Failed"
                    strings are available in all examples. This is a fix
                    for CR-965028.
      ms   03/17/17 Modified readme.txt file in examples folder for doxygen
                    generation.
</pre> </div></div><!-- contents -->
</div><!-- doc-content -->
<div id="nav-path" class="navpath"><!-- id is needed for treeview function! -->
  <ul>
    <li class="footer">Copyright &copy; 2015 Xilinx Inc. All rights reserved.</li>
  </ul>
</div>
</body>
</html>
